[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games

View post   
File: 49 KB, 600x450, 1638508164281.jpg [View same] [iqdb] [saucenao] [google]
8569935 No.8569935 [Reply] [Original]

i often hear that PS2 and Saturn were hard to develop for, or vice versa, that GC and PS were easy for devs. what would BE the tier list for this criteria then? I know MD was easy and SNES was hard, but I don't know about rest really, and how they compare.

>> No.8569938

>>8569935
That picture looks like something out of Yakuza 0.

>expects to be called a zoomer

>> No.8569954

>>8569935
>what would BE the tier list for this criteria then?
Hard to rank consoles of different generations unless you seek to do the exact same thing with each system - i.e. figuring out the code/dev environment required to draw a line on the screen.

>> No.8569963

Atari 2600: Balls hard. You have to redraw the playfield every frame and there is only 128 bytes of RAM
Colecovision: Not that bad but the NMI setup is a royal PITA
NES: Kind of annoying because you can't mess with the PPU while it's rendering the screen or it glitches out. More complicated games need bank switching. Reading the controller is a little annoying and there's no 6502 decimal mode or collision registers
Master System: Not too hard other than bank switching but there's only one standard banking setup unlike the NES. The lack of hardware sprite flipping is annoying.
Gameboy: Again, bank switching but same as the Master System there's only one standard banking setup. Screen real estate is small and 16k of ROM is fixed and can't be banked out so games can only have one engine
Mega Drive: Easy. Great CPU and no bank switching.
SNES: Painful. Shit CPU with segmented memory and only 16k sprite RAM.
PS1: Easy. Almost too easy so programmers complained and Sony responded by making the PS2 much harder.
Saturn: Nothing that hard about 2D stuff, 3D is ass and AIDS
N64: Easy if you want to make Mario Kart, awful if you want to make Conker's Bad Fur Day

>> No.8569979

>>8569963
2600 (and afaik 7800) have no VRAM in the modern sense, right? Always found that fascinating

>> No.8569984

The Atari Jaguar would be pretty high up there considering the hardware was actually broken and that had to be accounted for.

>> No.8569990

>>8569979
That racing the beam shit is crazy to me. It's amazing anyone managed to make anything at all.

>> No.8570010

>>8569963
thanks anon
what about 6th gen (including GBA)? what made ps2 so complex anyway?

>> No.8570021

>>8570010
The PS2's issue was mainly that it had an early multicore CPU and programmers weren't used to that yet.

>> No.8570030

gonna use this thread to ask, i always wanted to play around with Xbox development for fun. is it true that it was a breeze to develop for compared to the others?

>> No.8570062

>>8570030
Xbox was basically a Pentium 3 PC that made up for its relatively-cut down RAM by giving its full hardware resources to whatever was running at that moment.
Assuming a developer was already using a PC in some auxiliary way to develop games for, say, N64 or PS1, then certainly it must have been a relief to have the base development platform mirror the target platform. No need to learn the ins and outs of a new CPU and then strategically optimize everything for it.
If you have a P4-era PC with Win XP and a graphics card decent for the time, you can install the Xbox SDK and execute code on the Xbox over a network.

>> No.8570138
File: 61 KB, 1000x800, Apu_apustaja_peuku_koneenl_a.jpg [View same] [iqdb] [saucenao] [google]
8570138

>>8570062
thanks a bunch anon

>> No.8570294

we can do retro computers too while we're at it

Apple II: The bitmap screen is really lumpy and hard to work around; you will need look-up tables for everything. There's just a 1-bit speaker for sound that stops everything when you operate it and there are no IRQs.
Atari 8-bit: Not that hard in general except the sprites are kind of limited and annoying to use. The DLI system is pretty neat.
C64: Easy to just get a basic game running, tricky if you delve into advanced hardware tricks
ZX Spectrum: Think of it as an easier Apple II with worse storage options (tape instead of disks) The Z80 gives you more grunt than the 6502 and the bitmap screen is easy to use and can be manipulated at a pretty light CPU cost
Amiga: As with C64 a basic game is fairly easy to get running, advanced hardware tricks are...advanced.
Retro PCs: Real mode DOS stuff is crap because it uses 64k memory segments, CGA and EGA are crap. VGA and 32-bit you just program in C and it wouldn't be a lot different from a modern PC except with less memory and processing power.

>> No.8570316

>>8569963
>N64: Easy if you want to make Mario Kart, awful if you want to make Conker's Bad Fur Day
Stuff like CBFD and Infernal Machine used microcodes and other shit that isn't even properly emulated. Nintendo also kept that stuff secret and didn't give it out to devs other than Rare.

>> No.8570397
File: 367 KB, 778x1018, trash.jpg [View same] [iqdb] [saucenao] [google]
8570397

>>8570294
>no JPCs

>> No.8570419

>>8570294
>>8569963
Thanks anon, very insightful

>> No.8570440

>>8570294
what about the Archimedes?

>> No.8570485

>>8570294
>Apple II: The bitmap screen is really lumpy and hard to work around; you will need look-up tables for everything. There's just a 1-bit speaker for sound that stops everything when you operate it and there are no IRQs.
ain't nobody does any homebrew for this thing

>> No.8570753

>>8570485
It's not very nice to program, also the Apple II was pretty much only an American thing so Euros and whatnot don't care about it.

>> No.8570824

>>8570010
GBA was a breeze to develop for. Today it's probably the easiest homebrew platform to pick up.

>> No.8571030

if you don't see homebrew for it it's probably too hard/shitty to bother with

>> No.8571038

>>8569963
Man, by comparison, it looks like the NES was Nintendo's only reasonably designed console. You have to keep your expectations low for 1983, but by 1990 the SNES has no right being such a PITA.

>> No.8571040

>>8569963
>Atari 2600: Balls hard. You have to redraw the playfield every frame and there is only 128 bytes of RAM
Furthermore it can access only 4k of ROM at once.

>> No.8571043

>>8571038
GC was pretty sensible, but it was too little too late.

>> No.8571048

>>8571038
>Man, by comparison, it looks like the NES was Nintendo's only reasonably designed console

Gamecube and Wii are easy to develop for and pose no major challenges, they're just underpowered.

>> No.8571067

>>8571040
Activision had a banking system only in two games that intercepts JSR instructions and lets you access 32k as a single block. Otherwise normally you just split your ROM into separate 4k "programs" and switch between them.

>> No.8571086

>>8571067
>that intercepts JSR instructions
That caught my curiosity. What is it, a self modifying code thing?

>> No.8571097

>>8571086
no it's not like that.

https://atariage.com/forums/topic/315497-david-crane-talks-about-his-scabs/

>> No.8571116

>>8571097
it's actually a little cleaner than banking on NES, etc because it doesn't need trampoline code to link the different ROM banks

>> No.8571139

>>8571097
Oh, that's really cool too. Thanks.

>> No.8571158

>>8571116
NES/Master System/Gameboy banking is annoying because you always have to be flipping between banks as part of your code loop, especially flipping the music bank which is done like every frame.

>> No.8571278

>>8571043
>>8571048
GameCube was hamstrung by the minidisks and it not being the PS2. No one wanted to make games for it when it was such a weak seller. Developers will put up with hard architecture if the money is there.

>> No.8571559
File: 975 B, 640x380, turmoil (Sirious Atari 2600, 1982).png [View same] [iqdb] [saucenao] [google]
8571559

>>8569963
>>8569990
the nice thing about the Atari 2600 is games just got to the point and there wasn't 10 minute cutscenes and pretentious weeb storylines

>> No.8572168

>>8570294
>Apple II: The bitmap screen is really lumpy and hard to work around; you will need look-up tables for everything. There's just a 1-bit speaker for sound that stops everything when you operate it and there are no IRQs.
good thing is it's fast due to the interleaved memory refresh

https://www.youtube.com/watch?v=gMfKRhLnLy0

this game was only on Apple II and PC there was no Atari 8-bit, C64, etc port because it's got too much stuff moving around and they don't have enough sprites to handle it. the Apple and PC don't have the limitations of hardware sprites.

>> No.8572567

>>8570010
>6th gen
The Xbox was the easiest to program for because it's just a Windows PC converted into a console. The GC was pretty easy thanks to its simple architecture, it's a weak console compared to the PS2 if you need to do a lot of parallel calculations though. The GBA was really simple too.
>what made ps2 so complex anyway?
Tons of pipelines, SIMD processing. It's a really impressive console for the price if you pushed its capabilities to the limit though. Rockstar's Renderware was one of the engines that made good use of the CPU's functionalities.

>> No.8572581

>>8571030
and then you have stuff like the 2600, which gets homebrew specifically BECAUSE people want the challenge.

>> No.8572586

>>8571038
N64 would've been great if it hadn't used RDRAM, but SNES really should've been a completely different system.

>> No.8572590

>>8572567
>Rockstar's Renderware was one of the engines that made good use of the CPU's functionalities.
where exactly? I mean, obviously the open spaces were huge, but GTA models looked pretty damn angular even for their day.

>> No.8572648

>>8572590
It's full of small and moving objects. The engine has to render them all.

>> No.8572654

PS2 has TERRIBLE jagged antialiasing and interlacing due to a hardware bug ironically enough contributed to giving games a gritty low res look. It's objectively shitty look that kinda grows on you like dot crawl on the NES.

>> No.8572664
File: 59 KB, 630x470, front_mission_4_import_image8.jpg [View same] [iqdb] [saucenao] [google]
8572664

>>8572654
https://www.youtube.com/watch?v=BiT7aFfDExk
Front Mission 4 being my favorite example of this strange phenomenon.
PS2 polys look like fucking bone saw teeth and that somehow work to the benefit of some gritty games.
Compare this to Dreamcast, GC or XBOX silky smooth like a cartoon

>> No.8572731

>>8569963
>SNES: Painful. Shit CPU with segmented memory and only 16k sprite RAM.
It amazes me the amount of great games on there if it truly is this hard

>> No.8572771

>>8572731
because it attracted a lot of game development, but a lot of games were canceled or cut down because of the realities of dev schedules. the hardware isn't weak but it makes the programmer do a lot of extra work.

>> No.8572867

>>8570753
Your talents are wasted here man.

>> No.8573540

>>8572771
the audiovisual data eats more space than the equivalent on the Mega Drive so you can't fit as much content into the same ROM size

>> No.8573564

>>8570062
>If you have a P4-era PC
you can do it all from an XP VM.
>>8570138
https://www.youtube.com/watch?v=YN2t-D0cj48
MVG has a few vids on xbox dev, makes for a good introduction to setting it up. also consolemods.org/wiki/Xbox:Debug

>> No.8574254

>>8573540
not even talking about that, I'm talking about features being cut because they couldn't get them up and running.

>> No.8574267

>>8573540
>the audiovisual data eats more space than the equivalent on the Mega Drive
is there a specific technical reason for that?

>> No.8574275

>>8574267
More colors is a big one for graphics data.

>> No.8574280

>>8574267
bitplane graphics vs packed pixel graphics, and sampled audio vs synthesized audio.

>> No.8574287

>>8574275
no it's not, both systems use 16-color graphics which take up the same amount of space uncompressed, but the SNES can use more unique 16-color palettes across different objects. genesis graphics just compress better because they're formatted better.

>> No.8574495

SNES tiles take 64 bytes each while Mega Drive tiles are 32 bytes (NES tiles are 16 bytes)

>> No.8574525

>>8574495
>>8574287
also the SNES has three scrolling planes so that's more stuff to fill (even though you don't have to use all of them)

>> No.8575237

>>8574495
no they don't, only mode-7 tiles do (and a few other rarely-used modes). all other snes graphics are 16-color or 4-color.

>> No.8575584

>>8574495
It depends on the color depth used. The lowest depth is as little as 16 bytes per tile same as the NES while the highest depth is 64 bytes (Mega Drive tiles are always 32 bytes). Many early SNES games like SMW used only lower color depths to conserve space as they had to fit in 4 megabits.

>> No.8575686

>>8572586
Nintendo was really close with Sharp, right? What if the SNES was a cost reduced version of the X68000? Then again, I feel like Nintendo wouldn't want to have a console so similar to the Mega Drive, and with as stingy as they were the Mega Drive would run circles around their cut down version.

>> No.8575750

>>8575686
it should've been 32-bit with unified memory and a RISC cpu, and entirely sprite-based graphics with multiple bit depths and hardware transparency (and no other special effects since they can all be done in software). would be kind of like an atari jaguar without the 3D hardware, and vastly better for 2D arcade ports as well as software-rendered games. would need CD hardware to get the most out of it though.

>> No.8575941

>>8575686
>what if the SNES was a cost reduced version of the X68000?
All japanese 16 bit consoles and x68k have more or less the same tilemap based architecture. A cut down X68K wouldn't be much different from mega drive, it wouldn't even benefit from the VRAM. It would be better to make a cut down, more gaming oriented version of Amiga, the blitter would give plenty of performance benefits and new graphical effects for an affordable price. Get rid of the HAM mode and other computer features, keep only 128K of RAM.

>> No.8575948

>>8575941
it would have to be 32-bit, otherwise it would be worse than the original SNES.

>> No.8575956

>>8575948
The only reason the SNES is 8/16 bit is because Ricoh had the toolset to manufacture 6502 clones. To use the 68K nintendo would've only had to to pay something like $5 more, but they were jews.

>> No.8575965

>>8575956
Nintendo wanted NES compatibility originally that was the reason for the choice of CPU there.

>> No.8576004

>>8575750
>SNES(launched in late 1990, started development in late 1987)
>it should've been 32-bit with unified memory and a RISC cpu
ARM would have been the cheapest option back then, and the NEC RISCstations were retailing for about $6,000+. You honestly thinking the most expensive CPU around into a console and jacking the launch price of the SNES above $200 would have helped against the Genesis?

>> No.8576010

>>8576004
you can get it back below $200 by getting rid of that awful sound chip, some basic PCM running out of main memory would've been fine supplemented by FM.

>> No.8576031

>>8576010
>Just sell the consoles at $200 loss on the CPU alone!
Yeah, worked great for the Dreamcast. By '93 you could get a RISC chip for under $100, but in 1987 you weren't gonna. By 1990 they were still pricey and limited to servers and heavy-duty workstation computing.

>> No.8576052

>>8576031
well if you're talking 1987 then it should've just been the genesis with more colors, but the SNES came out in 1990. shouldn't have been impossible for them to swing something being nintendo and all. I guess it would've been going out on a limb though and a 68020 would've been the more likely option if they wanted to be 32-bit, or the atari panther route with 32-bit graphics and a 16-bit CPU.
I just think the SNES in 1990 was seriously dated tech and something more cutting-edge could've been really awesome.

>> No.8576082
File: 8 KB, 280x192, ultima iii.png [View same] [iqdb] [saucenao] [google]
8576082

>>8570294
>Apple II: The bitmap screen is really lumpy and hard to work around; you will need look-up tables for everything. There's just a 1-bit speaker for sound that stops everything when you operate it and there are no IRQs.

https://www.xtof.info/hires-graphics-apple-ii.html

this explains how it works. the screen is interleaved and pixel data also stored backwards against how it appears. meaning you actually have something like this.

>> No.8576097

>>8576052
>I just think the SNES in 1990 was seriously dated tech
>The NES launched in '83 with a CPU that launched in '75(8 year old tech).
>The SNES launched in '90 with a CPU that launched in '83(7 year old tech).
>The Genesis launched in '88 with a CPU that launched in '79(9 year old tech).
>The PC-Engine launched in '87 with a slightly upgraded version of a CPU that launched in '75(12 year old tech).
>The Game Boy launched in '89 with a slightly modified version of a CPU that launched in '76(13 year old tech).
>The Game Gear launched in '90 with a CPU that launched in '76(14 year old tech).
You need to start looking at things in context instead of as isolated events. Compared to everything else on the market, the SNES was the least dated tech in the room. Not the strongest, but not the oldest by any stretch.

>> No.8576102

>>8571559
That's what I was thinking, seems like ALL the hard work in making a 2600 game is chasing the beam. Once you have that down all you're doing is coding like two screens and a couple player sprites moving around to make a number go up.

>> No.8576109

>>8576052
>atari panther route
The Panther didn't have any tile hardware. It's an Atari Lynx on coccaine where you're able to render and move around an infinite number of sprites using memory blitter and object processor. Jap devs would probably find it difficult to program for, this is a console for for Amiga CHADS.

>> No.8576123

>>8576097
The Panther was to be released in 1991, and it would've eaten the SNES alive performance wise. The SNES CPU was weak as shit and had no 32-bit functionality. What you need to understand is those CPUs might've been launched long before the release of those consoles, but consoles started using them once their price went down. The 68000 [roce dropped from something like $100 to $15 in 1984, there's literally no reason for nintendo not to use it by 1990 instead of their weak 8 bit shit.

>gameboy
>game gear
No, they're using the new CMOS version of those old CPUs.

>> No.8576125

>>8576102
you basically just have to update the sprite counters, read the joystick, and check for collisions. that's it.

>> No.8576126

>>8576097
the issue is it's the same basic architecture as the other 4th-gen consoles, just milking it harder. SMS pushes about twice as much graphics data as NES, and PCE about twice as much as SMS (and NES about twice as much as colecovision). then that stopped all of a sudden with SNES. it was legitimately behind the curve for its time. the RISC thing is just if you wanted to push it as hard as possible.

>> No.8576139

>>8576109
they did fine with the playstation though, which is basically the same thing where 2D is concerned.

>> No.8576215

>>8576109
I thought it used line buffer graphics from ROM, which is nothing like the lynx but a lot like the 7800.

>> No.8576224

>>8576215
The 7800 has no blitter and object processor. Panther draws each frame in a buffer and displays it instantly.

>> No.8576246

>>8576224
"blitter and object processor" is what the jaguar has, panther only has the object processor which is the part that just displays sprites and draws line buffer graphics. it doesn't blit because it doesn't have the RAM to do a frame buffer. that means the objects it can draw are scanline-limited, but the limit is very high because it's 32-bit and has hardware compression routines.

>> No.8576254

>>8570316
Is this more reason F Zero X run native 60fps?

>> No.8576271

>>8576246
It has a 32Mhz object processor. I'm sure it's the same object processor used in the Lynx, only twice as fast. And I'm also absolutely sure that 32KB RAM listed woudln't be in the finalized spec, the only existing prototype was made to run Pong as a test.

>> No.8576275

>>8570294
Any suggestions information on JP exclusive computers?
>>8572731
>>8574287
See>>8575686

>> No.8576278

>>8576123
>SNES was weak 8 bit shit
I'm sensing an axe to grind here.
>but the GB and GG, those were using DIFFERENT versions of the CPU!
Yes, specifically the low-power versions. Since they are handhelds.

>>8576126
The 6502 variant in the NES is just the same basic architecture as the 2nd generation's 2600, just milking it harder. The SNES was on par for the competition.

>> No.8576295
File: 2.04 MB, 1648x672, panther proto.png [View same] [iqdb] [saucenao] [google]
8576295

Screenshots of Atari Panther graphic demos.

>> No.8576313

>>8576278
>I'm sensing an axe to grind here
68000 could address much more memory since it's got 24 bit addressing and 32 bit registers.
>specifically the low-power versions
Which weren't available before. CMOS technology sucked until the late 80s.

>> No.8577115

>>8576313
>68000 could address much more memory since it's got 24 bit addressing
So does the 65816.

>> No.8577121

>>8577115
Only using segmentation, which is a pain in the ass.

>> No.8577127

>>8569984
Have you considered doing the math?

>> No.8577132

>>8569963
Atari 2600 programming, at least back then, was like a pedigree job. Apparently there were only like 100 people in the world who knew how to handle the thing to its best abilities, without games being a buggy disaster or laughably simple. I’m sure atari gathered up all the talent they could muster and shipped them out to Atari HQ so people like Howard Scott Warshaw were all crammed together in one office space churning out games like their lives depended on it

>> No.8577136

>>8577132
>Apparently there were only like 100 people in the world who knew how to handle the thing to its best abilities, without games being a buggy disaster or laughably simple
we saw what happened when you let any code monkey make a game for it. the result was Karate and Warplock.

>> No.8577142

>>8577136
I think that’s why people tended to stick to simple games at the time, or single screen ones. Making something that was slightly more advanced than Asteroids was basically like getting struck by lightning and being dealt a royal flush while being crushed by a falling satellite. Astronomically rare and astronomically difficult. I mean damn, even the staff in Atari who knew what they were doing were still struggling. Raiders of the Lost Ark, also by Howard Scott is a pretty impressive game for the system but I’ll be damned if it isn’t totally crippled by the hardware

>> No.8577151

>>8577142
>>8577132
That game and ET fell victim to the old curse of Western game developers which was trying to make a PC game on a console. Japanese didn't make that mistake, they were smarter at realizing a console was mainly good at moving graphics around and they didn't try to shoehorn in puzzle/exploration elements that don't work when you don't have a keyboard or a large amount of RAM.

>> No.8577169

>>8577151
That’s not entirely fair. The 2600 was about 6 years old at the time and the devs were really pushing it as far as they could possibly go. Raiders is an example of aiming too high, while ET was just the result of a rushed development cycle. Those were rare examples though, as in I can only really think of those two games being too advanced for the system. Nearly every other game made for the thing kept it simple. The Japanese were also making consoles around the time that had the same specs, or sometimes even worse, and they were making similar games. Look at the wave of Casio consoles that flooded the market with identical looking hardware, or the SG1000 which was basically just a Japanese collecovision. It was only when the NES came out that things started getting more advanced and workable. PCs are an entirely different kettle of fish.

>> No.8577175

>>8576275
NEC machines were not all that interesting from a technical standpoint, basically a PC with higher resolution graphics. they just have a frame buffer and there's no sprites or anything.